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Procede de creation de fichiers de configuration d'objets inclus dans.un 
systeme infonmatique. 

DESCRIPTION 
Domaine technique 

La presents invention se rapporte a un procede de creation de fichiers 
de configuration d'objets appartenant a un systeme informatique, 

Le systeme informatique comprend des objets materiels (machines, ...), 
et/ou logiciels (applications. ...). Ce systeme est indifferemment un systeme 
distribue ou non, heterogene ou non. 

Les objets comprennent des parametres inclus dans un fichier de 
configuration. L'invention s'applique a tout fichier de configuration ecrit dans un 
langage de balisage extensible, c'est-a-dire un langage qui presente de 
rinformation encadree par des ballses. Le fichier de configuration est ecrit en 
utilisant un metalangage de description dont le format est independent du 
materiel et/ou logiciel a configurer. Un metalangage se defini generalement 
comme etant un langage utilise pour decrire un autre langage. Le langage de 
balisage XML (extensible Markup Langage), connu de Thomme du metier, est 
bien adapte a la mise en oeuvre de la presente solution. Rappelons que la 
specification du langage XML est definie par le consortium W3C (Worid Wide 
Web Consortium). Ce consortium est un Organisme de promotion du «World 
Wide Web». qui met au point des normes et des protocoles ouverts et libres. 
dans un souci dMnteroperabilite maximale. Le fichier de configuration XML a 
une structure declaree dans un fichier de description. Ce fichier de description 
comprend la description des parametres de configuration d'un objet et se 
nomme generalement Definition de Type de Document (DTD), Cette definition 



s'effectue selon un formalisme particulier egalement defini dans la specification 
XIVIL du consortium W3C. 

L'art anterieur 

Par definition, I'ecriture d'un fichier de configuration dans un langage 
XML doit obeir a certaines contraintes syntaxiques. En effet. un document XML 
a une structure logique. II se compose de descriptions, d'elements, de 
commentaires, d'appels de caractere et d'instructions de traitement, qui sont 
Indiques dans le document par I'intermediaire d'un baiisage explicite. Les 
elements sont encadrees par de ballses ouvrantes, par exemple <preface>, et 
des balises fermantes, par exemple </preface>. Les elements sont structures et 
decrivent les parametres des objets. Les parametres, comme un attribut d'un 
objet, peuvent etre Indus a I'interieur meme des balises. Par exemple, on peut 
ecrire <LIVRE sujet = k> signifiant que I'attribut sujet de I'element LIVRE a la 
valeur K. 

Dans notre exemple de realisation, Les parametres des objets sont 
definis dans un fichier de configuration ecrit dans un langage XML tel que 
defini precedemment. 

Le probleme principal est que les objets a configurer se comptent en 
milliers et que plusieurs de ces objets peuvent se reposer sur un meme fichier 
de description DTD et avoir des valeurs identiques pour tout ou partie de leurs 
parametres. Pour construire le fichier de configuration, I'administrateur du 
systeme de gestion doit alors valoriser les parametres d§crit dans le fichier de 
description autant de fois qu'il y a d'objets se reposant sur ce fichier DTD. Plus 
precisement, supposons que deux objets B1 et B2 se reposent sur un m§me 
fichier de description (DTD). Pour configurer I'objet B1, I'utilisateur doit 
valoriser tous les parametres decrit dans le fichier DTD. Pour configurer I'objet 
82, rutilisateur doit a nouveau valoriser tous les parametres decrit dans le 
fichier DTD. En consequence, les parametres de meme valeur sont ecrit autant 
de fois qu'il y a d'objets se reposant sur un meme fichier de description. 
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L'ecriture d'un fichier de configuration presente done des redondances. Le 
langage XML etant un langage de configuration da bas niveau, un utilisateur 
est done eontraint d'ecrire dans le fichier de configuration des descriptions de 
parametres repetitives dont la semantique est. dans certains cas, sans rapport 
5 avee ses besoins, ce qui necessite une culture importante de sa part de 
Tensemble des syntaxes offertes par le langage XML. De ce fait, le fournisseur 
doit foumir avee le fichier de description une documentation precise. II est clair 
qu'un fichier de configuration impose un cout eri temps important en ecriture. 

Un autre probleme, lie au nombre important d'objets a decrire, est que si 
10 un utilisateur situe sur une machine quelconque du reseau souhaite visualiser 
des ressources du systeme informatique configurees dans le fichier de 
configuration, le systfeme de gestion doit alors transmettre le fichier de 
configuration a la machine distante par Tintermediaire du reseau. Lorsque le 
fichier de configuration a un gros volume, le flux de donnees entre le systeme 
15 de gestion et rapplication cliente peut s'averer tres important et conduire a 
saturer le systeme de communication entre les applications clientes et le 
systeme de gestion. 

Enfin. un autre probleme est que la syntaxe definie selon les 
recommandations du consortium W3C doit etre respect6e a la lettre tout au 
20 long de Tecriture du fichier de configuration. Le risque d'erreur lors de Tecriture 
d'un fichier de configuration est done permanent pour un adminlstrateur du 
systeme de gestion. 

Sommaire de rinvention 

25 Un premier but de la solution est done de simplifier considerablement 

i'ecriture des fichiers de configuration reduisant en consequence a la fois le 
cout en temps d'ecriture de celui-ci et le risque d'erreurs d'ecriture. 

Un deuxieme but vise est de reduire la taille du fichier de configuration. 
A cet effet. la solution a pour objet un precede de creation d'au moins un 
30 fichier de configuration d'objets materiels et/ou logiciels presents dans un 
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systeme informatique, ledit fichier de configuration etant ecrit en utilisant un 
metalangage de description dont le format est independent du materiel et/ou 
logiciel a configurer, ce fichier de configuration incluant tout ou partie des 
parametres desdits objets et se reposant sur un fichier de description 
definissant des contraintes a respecter sur la structure et la syntaxe lors de 
I'ecriture dudit fichier de configuration, caracterise en ce qu'il consiste a 
etendre le fichier de description par au moins un modele comprenant au moins 
un parametre decrit dans le fichier de description, et en ce qu'il consiste a 
valoriser tout ou partie des parametres de ce modele. 

II en resulte egalement un fichier de configuration d'objets materiels 
et/ou logiciels presents dans un systeme informatique, ledit fichier de 
configuration etant ecrit en utilisant un metalangage de description dont le 
format est independent du materiel et/ou logiciel a configurer, ce fichier de 
configuration incluant tout ou partie des parametres desdits objets et se 
reposant sur un fichier de description definissant des contraintes S respecter 
sur la structure et la syntaxe lors de I'ecriture dudit fichier de configuration, 
caracterise en ce que le fichier de description est etendu, en ce que I'extension 
comprend au moins un modele incluant au moins un parametre inclus dans le 
fichier de description, et en ce que une partie des parametres de ce modele 
20 sont valorises. 

L'invention sera mieux comprise a la lecture de la description qui suit, 
donnee a titre d'exemple et faite en reference aux dessins annexes. 

25 Description d'un exemple de realisation 

Dans les dessins : 

- la figure 1 est une vue synoptique de I'architecture d'un systeme 
informatique sur lequel peut s'appliquer la solution. 



13 



figure 2, est une vue d'un modele conforme a la presente solution. 
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Sur la figure 1 . on a represente un systeme informatique SYS distribue 
illustrant un example de realisation prefere de la solution. Dans rexemple 
iilustre, ce systeme SYS inclut un systeme de gestion SG et au moins une 
machine M1. Le systeme de gestion SG comprend au moins un systeme 

5 d'exploitation, au moins une memoire de stockage d'informations et au moins 
un processeur controlant le processus du traitement de rinformation. Le terme 
gestion est utilise pour etre conforme a la traduction Afnor (Association 
Frangaise de NORmalisation) de « Management ». Un systeme de gestion de 
machines de type « Open Master » (marque deposee par la societe BULL 

10 S.A.), connu de Thomme du metier, est particulierement bien adapte pour la 
mise en oeuvre de la solution. Ce systeme de gestion peut etre assimile a un 
ensemble de services qui interagissent entre eux pour donner une 
representation objet du monde reel constitue notamment par les machines du 
systeme informatique. C'est une representation objet qu'un administrateur 

15 manipule (surveillance, action) pour gerer le monde reel. La representation 
objet porte sur des objets virtuels du monde reel et constitue un modele objet. 
En d'autres mots, un objet gere par le systeme de gestion est une vue 
abstraite, definie pour les besoins de gestion, d'une ressource logique ou 
physique du systeme informatique. (disque, processeur, memoire, etc.) et/ou 

20 logiques (fichiers. processus, semaphores, etc.). 

Le systeme de gestion et les machines qu'il gere constitue une 
architecture Client/Serveur. Dans une telle architecture, un application cliente 
interroge le systeme de gestion pour connaitre I'etat des objets geres par le 
systeme de gestion. Le mode client/Serveur a I'avantage de permettre a un 

25 utilisateur appele client (ou application cliente) situe sur une machine, par 
exemple par Tintermediaire d'un simple micro-ordinateur ou d'une station de 
travail, de confier une partie de sa tache ou de ses operations a effectuer au 
serveur a savoir le systeme de gestion. D6 cette maniere, le client dispose 
d'une capacite de calcul beaucoup plus importante que celle de son micro- 

30 ordinateur. 
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Le systeme informatique peut etre heterogene. Afin de masquer 
rheterogeneite du systeme informatique, le systeme de gestion SG et les 
machines gerees par le systeme de gestion comprennent au moins un agent 
respectif associe a un protocole de gestion. Un agent assure, entre autres, une 
. conversion de protocole. 

Le systeme de gestion est relie a une machine geree par I'intemiediaire 
d'un reseau quelconque. Le reseau peut etre de type LAN (Local Area 
Network). WAN (Wide Area Network). Un ensemble de couches logicielles 
s'interpose entre le systeme de gestion SG et le reseau RES et entre le reseau 
et chaque machine. Pour des raisons de simplification de la desaiption, cet 
ensemble de couches logicielles n'est pas represente sur la figure 1. 

Chaque objet ger6 comprend des parametres d^finis dans un fichier de 
configuration de preference ecrit dans un langage de description S baiisage 
comportant une structure et incluant tout ou partie des parametres (nom, au 
moins un attribut, au moins une action, etc.) des objets. Le fichier de 
configuration se base sur un fichier distinct appele fichier de description 
definissant les contraintes sur la structure et les contraintes syntaxiques des 
parametres pour I'ecriture dudit fichier de configuration associe a un objet 
d'une machine. De preference, le fichier de configuration est ecrit dans un 
langage de type XML, et le fichier de description est un fichier de description 
de type DTD. connus de I'homme du metier. Dans notre exemple de realisation, 
ce fichier de configuration XML et le fichier de description DTD sont inclus 
dans le systeme de gestion SG. 

Dans notre exemple de realisation, le fichier de description DTD est 
centralise sur le systeme de gestion de fagon a etre utilisable par toutes les 
machines du reseau. De preference, les objets geres peuvent etre representes 
par un arbre. chaque noeud de I'arbre representant un objet gere. Une 
application de visualisation APV incluse sur la machine M1 peut interroger le 
fichier de configuration dans le but de recevoir les parametres des objets 
configures et de visualiser ces objets sur cette machine. De preference, pour la 
visualisation des parametres de configuration des objets, la machine M1 est 
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munie d'un navigateur standard dit « Internet Explorer ». connu de rhomme du 
metier, dans lequel un programme en langage JAVA est execute pour lire le 
fichier de configuration, accedant ainsi a son contenu et a sa structure, et pour 
transmettre les informations lues a (aux) applications de visualisation APV. 

5 

Description de parametres de configuration d'un obiet : 

Un objet comprend comme parametre au moins un attribut. Par example, 
un attribut ID est Tidentificateur de I'objet. un autre attribut Pr'PE designe son 
type, et un autre attribut OWNER. De plus, un objet a des proprietes. Dans 
10 notre exemple, un objet comprend egalement comme parametres: 

■ le nom de Tobjet. 

■ les actions que Ton peut executer sur cet objet incluant Taction ouvrir 
pour Touverture du noeud, Taction fermer pour la fermeture du noeud, Taction 
developper pour visualiser les noeuds subordonnes a un noeud, 

15 ■ et des proprietes graphiques de ce noeud incluant le type de police 

de caractere, Tadresse de Ticone qui lui est associe, et la couleur de fond 
desiree 

Ainsi, dans ce fichier de description DTD, un element « noeud » est 
associe a un noeud, et des elements lui sont subordonnes et sont associes 
20 respectivement 

■ au nom de Tobjet 

■ aux actions (ouvrir, fermer. developper) que Ton peut executer sur cet 

objet, 

■ et aux proprietes graphiques (police de caractere, icone, couleur de 
25 fond) de cet objet. 

Des attributs peuvent etre associe a un element. Dans notre exemple de 
realisation, Telement « noeud » comprend trois attributs a savoir : 

■ un attribut ID designant son identificateur 

■ un attribut TYPE designant son type 

30 ■ et un attribut designant son proprietaire 
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Un fichier de description DTD definissant un objet de I'arbre peut etre 
ecrit de la fa9on suivante, en respectant le formalisme particulier defini dans la 
specification XML du consortium W3C : 

< ! ELEMENT noeud (noeudNonn, noeudActions, 

noeudProprieteGraphique)> 

< ! ELEMENT noeudActions (action*) > 

< lELEMENT noeudNom (groupeNonn, odresseNom, ver3ionNom)> 

< lAHLIST noeud Id CDATA #REQUIRED 

TypeCDATA ^REQUIRED 
Owner CDATA #REQUIRED 

> 

< I ELEMENT noeudProprietegrophique (police, icone, couleur)> 

Dans ce fichier, CDATA #REQUIRED siginifie que I'attribut en question 
doit etre un bloc de texte contenant des caracteres. De plus, I'ecriture 
« action* » signifie que les actions n'ont pas d'attributs et que la syntaxe de ces 
actions a utiliser lors de I'ecriture du fichier de configuration est du texte. 

L'ecriture OELEMENT noeudNonn (groupeNonn, odresseNom. 
version Nonn)> indique que I'element « noeudNom » comprend trois elements 
(groupeNonn, cdresseNonn, verslonNom) qui lui sont subordonne. L'element 
« groupeNonn » designe le nom de I'objet, I'element « odresseNom » designe 
I'adresse de I'objet, et I'element « version Nom » designe la version de I'objet. 

Ce fichier de description correspondra dans la suite de la description au 
fichier de description initialement cree. 

Notons que le nombre de parametres dans notre exemple de realisation 
est reduit pour des raisons de simplification de la description. En general un 
fichier de description comprend un nombre de parametres plus important. 

Dans I'exemple illustre, supposons par exemple que trois objets (0BJ1 , 
0BJ2 et OBJ3) se reposent sur le meme fichier de description DTD defini plus 
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haut. Le probleme principal est que, pour construire le fichier de configuration, 
radministrateur du systeme de gestion doit valoriser les parametres decrit dans 
le fichier de description autant de fois qu'il y a d'objets se reposant sur ce 
fichier DTD. Uadministrateur doit done completer le fichier de configuration 

5 trois fois. Le cout en temps d'une telle ecriture est done considerable. 

A cet effet. la solution consiste a etendre le fichier de description par au 
moins un modele comprenant au moins un parametre Indus dans le fichier de 
description, et en ce quMI consiste a valoriser une partie des parametres de ce 
modele d'element. En Uespece. la solution consiste a introduire un modele 

10 d'element dont Tecriture respectent des proprietes definies dans ce qui suit. 

Dans notre exemple de realisation, nous avons a definir un ensemble 
d'objets dont les seuls parametres variant entre eux sont 

- relement « Norn » correspondent au nom des objets (0BJ1, 0BJ2 et 
0BJ3), respectivement (JAZZ, POP, SOL), 

js - et Tattribut « ID » correspondent a Tidentificateur des objets (0BJ1. 

0BJ2 et 0BJ3), respectivement (123, 142, 162). 

Ces deux parametres seront dits indefinis dans le suite de la 
description. Dans I'exemple de realisation, les objets (0BJ1, 0BJ2 et 0BJ3) 
ont un nom respectif (JAZZ, POP. SOL) et un identificateur respectif (123. 142, 

20 162). 

Conformement a notre hypothese de depart, les autres parametres ont 
la meme valeur pour cheque objet (0BJ1, OBJ2 et 0BJ3). lis seront dits 
definis. Ainsi, 

■ la valeur de Telement correspondant aux actions que Ton peut 
25 executer est la meme pour cheque objet (0BJ1 , 0BJ2 et 0BJ3), 

■ la valeur de Telement correspondant aux proprietes graphiques est la 
meme pour chaque objet (0BJ1, OBJ2 et 0BJ3) . 

et la valeur des attributs 
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■ TYPE designant le type du objet est le meme pour chaque objet 
(OBJ1. 0BJ2 etOBJ3). 

■ et OWNER designant son proprietaire est le meme pour chaque objet 
(OBJ1, 0BJ2 etOBJS). 

Pour des raisons de simplification de la description, on donnera des 
valeurs arbitraires aux parametres definis. Dans notre exemple, la valeur de 
I'element correspondant aux actions que I'on peut executer sur chaque objet 
(0BJ1. 0BJ2 et 0BJ3) est ACT1 pour la commande « ouvrir », ACT2 pour la 
commande « fermer », et ACTS pour la commande « developper ». De meme, 
la valeur de I'element con-espondant aux proprietes graphiques de chaque 
objet (0BJ1. 0BJ2 et 0BJ3) est PR01 pour la police de caractere, PR02 pour 
I'icone. et PROS pour la couleur de fond. Enfin, les attributs TYPE et OWNER 
prennent pour chaque objet (0BJ1, 0BJ2 et 0BJ3) respectivement les valeurs 
« snmp » et « operateur ». 

Les deux etapes principals du precede conforme a la solution sont 
respectivement 

- I'ecriture du fichier de description DTD et de I'extension associe a ce 
fichier constitue par au moins un modele d'element (etape 1 ), 

- et I'ecriture du fichier de configuration resultant de la valorisation des 
parametres indefinis du modele d'element (6tape 2). 

Ecriture du fichier de desnri ption et introduction ri^ ja notion da 
modele d'element d ans un fichier de description : 

La premiere etape doit realisee en respectant certaines proprietes. Les 
parametres de ces objets dont la valeur est invariante etant identifies, la 
solution consiste a introduire le modele d'element MODELE dans le fichier de 
description DTD cree. Le modele d'element se distingue des autres elements 
du fichier de description en ce sens qu'il comporte au moins un parametre avec 
une valeur. 
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Premierement. le modele comprend. en respectant le fomnalisme 
d'ecriture d'un fichier de description DTD defini dans la specification XML du 
consortium W3C. 

- una entete MODELE avec un nom specifique « tnoeud » 

5 - et une reference a un element « noeud » defini du fichier de 

description DTD cree initialement. 

Le modele MODELE peut etre ecrit de la fa^on suivante : 
< IMODELE tnoeud ELEMENT =noeud > 

signifiant que le modele MODELE a un nom specifique « tnoeud » et 
10 qu'il se base sur la description de Telement « noeud » defini au prealable dans 
le fichier de desciption (DTD). 

Deuxiemement, dans ce modele. Tecriture des elements indefinis est 
particuliere. De fa^on a distinguer un element defini d'un element indefini dans 
le modele d'element. les elements a definir sont reperes dans ce modele par 

15 rintermediaire d'une balise specifique dont Tentete est par exemple 
< ! DEFINIR... >. De plus, les elements a definir sont identifies par un nom 
« tnoeudNom » et une reference a un element noeudNom du fichier de 
description initial precisant sur quel element du fichier de description 
prealabiement defini se base le modele d'element « tnoeudNom ». Dans notre 

20 exemple, un element a definir peut s'ecrire de la fa^on suivante : 

< IDEFINIR tnoeudNonn..,ELEMENT noeudNom >. 

A la difference des elements indefinis, les elements definis du modele 
d'element sont ecrits de la meme fafon que pour I'ecriture d'un fichier de 
25 configuration XML. 

Troisiemement, I'ecriture des attributs indefinis respecte des proprietes. 
Dans ce modele, les attributs a definir et definis, la solution consiste a 
introduire deux mots des DEFINIR et DEFINI indiquant qu'un parametre 
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attribut est a definir (DEFINIR) ou est defini (DEFINI). Dans notre exemple, 
I'attribut ID est a definir lors de i'ecriture du ficliier de configuration, tandis que 
les attributs TYPE et OWNER sont definis et prennent respectivement les 
valeurs « snmp » et « operateur ». Dans notre exemple, la liste d'attributs est 
relative au modele d'element MODELE « tnoeud » et peut s'ecrire de la fa?on 
suivante ; 

< ! AHLIST tnoeud 

ID DEFINIR 

TYPE DEFINI « snmp » 
OWNER DEFINI « operateur » 

> 

En definitive, le fichier de description DTD qui decoule d'une telle 
configuration peut s'ecrire de la fa^on suivante : 

< IMODELE tnoeud ELEMENT=noeud 

< IDEFINIR tnoeudNom ELEMENT=noeudNom> 

< noeudActions > 

<actlon nom=ouvrir> ACTl </action> 
<action nom=fermer>ACT2</action> 
<action nonn=developper>ACT3</actlon> 
</ noeudActions > 

< noeudProprietesgrophiques > 

<police de carccteres PROl ... /> 

<lc6ne>PR02</lc6ne> 

< couleur de fond PR03/> 

< / Proprietesgraphiques > 
> 

< I AHLIST tnoeud 

ID DEFINIR 

TYPE DEFINI « snmp » 
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OWNER DEFINI « operateur» 

>. 

Ce fichier constitue un facteur commun FC pour recriture du fichier de 
configuration et decrit les parametres (element et/ou attribut) a definir. 

5 

Ecriture du fichier de configuration 

La figure 2 est une vue du fichier de configuration qui resulte de 
I'utilisation du modele d'element. 

L'ecriture du fichier de configuration correspond a la deuxi^me etape. 

10 Cette operation consiste a utiliser le modele d'element MODELE defini dans le 
fichier de description DTD et a valoriser les elements et attributs indefinis. Lors 
de recriture du fichier de configuration, la solution consiste a utiliser la partie 
comprenant les parametres valorises comme facteur commun. et en ce que 
recriture se limite a la valorisation des parametres ne comportant pas de 

15 valeur. 

En respece, trois objets (0BJ1, 0BJ2 et 0BJ3) ayant pour nom 
respectif (JAZZ, POP. SOL) et un identificateur respectif (123, 142. 162) sont a 
configurer et I'ecriture du fichier de configuration pour ces trois objets se limite 
a ecrire les trois blocs suivants (81 . 82 et 83) : 

20 (Bl) 

<tnoeud ld==«123)» 
< tnoeudNom > 
<noeudNom> 

<groupeNom> JAZZ </groupeNom> 
25 <adresseNom> dbO </ adresseNom > 

<versionNom> 8.0 <ver5ionNom> 
</noeudNom> 
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</ tnoeudNom > 
</tnoeud> 

(B2) 

< tnoeud ld= «142}» 

< tnoeudNom > 

<noeudNom> 

<groupeNom> POP </groupeNom> 
<adresseNom> dbl </ odresseNom > 
<versionNom> 8.1 <versionNom> 
</noeudNom> 
</ tnoeudNom > 
<ltnoeud> 

(B3) 

<tnoeud ld= ((]62)» 

< tnoeudNom > 

<noeudNom> 

<groupeNom> SOL </groupeNom> 
<adresseNom> db2 </ odresseNom > 
<versionNom> 8.2 <versionNom> 
</noeudNom> 
</ tnoeudNom > 
<ltnoeud> 

Le nombre dMnvocation du modele d'element correspond au nombre 
d'objets se reposant sur ce modele MODELE. Ces trois blocs ont pour meme 
facteur commun celui cree dans le fichier de description. 

Selon une variante, un modele d'element peut contenir d'autres modeles 
d'elements. Ainsi, dans un fichier de configuration, on peut utiliser a Tinterleur 



d'une reference de modele d'element (par exemple « tnoeud ») une autre 
reference de modele d'elements. En effet, supposons qu'il existe dans le fichier 
de description DTD un modele d'element « tOracleNoeudNom ». dont les 
elements definis sont 

■ Telement nomme groupeNom 

■ et Telement versionNom 

et dont Teiement indefini est adresseNom. L'ecriture de ce modele d'element 
peut etre le suivant : 

< IMODELE tOracleSNodeName ELEMENT=noeudNonn 

<groupeNonn> Oracle </groupeNonn> 

< IDEFINIR tOracleDb ELEMENT=adresseNonn> 

<versionNonn> 8.0 <versionNonn> 

> 

De cette fa^on. lors de Tecriture du fichier de configuration, on peut 
utiliser le modele « tOracleNoeudNom » pour definir {'element noeudNom. Le 
fichier de configuration s'ecrit alors de la fa^on suivante : 

< tnoeud ld= «123»> 
< tnoeudNom > 

< fOracle8NoeudNom> 

<tOracleDb> 

<adresseNonn> dbO </adresseNonn> 
</ tOracleDb> 
</ tOracle8NoeudNom> 
<l tnoeudNom > 
</tnoeud> 

D'une maniere generate, la solution a pour objet un precede de creation, 
dans un systeme informatique, d'au moins un fichier de configuration d'au 
moins un objet materiel et/ou logiciel comprenant des parametres, ledit fichier 
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de configuration etant ecrit en utilisant un metalangage de description dont le 
format est independant du materiel et/qu logiciel a configurer, ce fichier de 
configuration incluant tout ou partie des parametres dudit objet et se reposant 
sur un fichier de description definissant des contraintes a respecter sur sa 
structure et sa syntaxe lors de son ecriture. caracterise en ce qu'il consiste, 
avant Tecriture du fichier de configuration, a etendre le fichier de description 
par au moins un modele comprenant au moins un parametre decrit dans le 
fichier de description, et a valoriser tout ou partie des parametres de ce 
modele. 

Ensuite, lors de Tecriture du fichier de configuration, la solution consiste 
a utiliser la partie du modele comprenant les parametres valorises comme 
facteur commun, et en ce que Tecriture du fichier de configuration se limite a la 
valorisation des parametres ne comportant pas de valeur. 

Lors de la creation du modele, on a vu que la solution peut consister 
tout d'abord a regrouper les objets se reposant sur le meme fichier de 
description, ensuite a identifier les parametres dont la valeur est identique 
entre tous ces objets, et enfin e a valoriser ces parametres pour constituer uh 
facteur commun dans ce modele. 

La solution consiste par exemple, lors de I'ecriture du fichier de 
configuration, si au moins deux objets se reposent sur le meme modele, a 
utiliser le facteur commun et a valoriser uniquement le restant des parametres 
de ce modele autant de fois qu'il y a d'objets se reposant sur ce modele 
d'element. 

Le langage utilise est extensible. Dans notre exemple, on a vu que la 
solution consiste a donner un nom pour identifier le modele dans le fichier de 
description, et en ce qu'il consiste a inclure dans le modele une reference du 
fichier de description, cette reference definissant les contraintes a respecter 
sur la structure et la syntaxe de ce modele. On a vu egalement que dans notre 
exemple, la solution consiste a introduire dans un modele deux mots des 
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DEFINIR et DEFINI indiquant qu'un parametre est a definir (DEFINIR) ou est 
defini (DEFINI) dans ce modele. 

De preference, le langage du fichier de configuration est le langage 
XML, la solution consistant a prendre comme parametre un element et/ou un 

5 attribut d'un objet. Selon cette variante, la solution consiste a etendre le fichier 
de description par au moins un modele d'element comprenant au moins un 
parametre (element et/ou attribut) decrit dans le fichier de description, et a 
valoriser tout ou partie des parametres de ce modele d'element. De meme, la 
solution consiste a donner un nom pour identifier le modele d'element dans le 

10 fichier de description, et en ce qu'il consiste a inclure dans le modele une 
reference a un element du fichier de description, cette reference definissant les 
contraintes a respecter sur la structure et la syntaxe de ce modele. 

Enfin, on a vu que, sur requete d'une application utilisant le fichier de 
configuration, la solution peut consister a transmettre le facteur commun et les 
15 blocs resultant de la valorisation des elements indefinis. 

Enfin. il en resulte un fichier de configuration d'au moins un objet 
materiel et/ou logiciel comprenant des parametres. ledit fichier de configuration 
etant ecrit en utilisant un metalangage de description dont le format est 
independant du materiel et/ou logiciel a configurer, ce fichier de configuration 

20 incluant tout ou partie des parametres dudit objet et se reposant sur un fichier 
de description definissant des contraintes a respecter sur sa structure et sa 
syntaxe lors de son ecriture, caracterise en ce que le fichier de description est 
etendu. et en ce que Textension comprend au moins un modele. 

En conclusibn, la solution offre de nombreux avantages. Un premier 

25 avantage est la simplification considerable de I'ecriture d'un fichier de 
configuration. En effet, les parametres definis etant valorises dans le modele 
d'element, Tecriture du fichier de configuration se limite a la valorisation des 
parametres ipdefinis. En consequence, Tadministrateur evite ainsi la repetition 
de parametres identiques entre objets. Le cout en temps d'ecriture et le risque 

30 d'erreurs d'ecriture lors de I'ecriture du fichier de configuration est largement 
reduit. De plus, T introduction d'un facteur commun dans le modele reduit 
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considerablement la taille du fichier de configuration. Avantageusement, sur 
requete d'une application cliente, le systeme de gestion transmet le fichier de 
configuration incluant ie facteur commun du modele d'element et, pour chacun 
des objets, les parametres de ce modele d'element qui ont ete valorises lors de 
I'ecriture du fichier de configuration. La taille du fichier de configuration etant 
reduit, le transfer! de ce fichier s'effectue done plus rapidement. 




REVENDICATIONS 

1- Procede de creation, dans un systems informatique, d'au moins un 
fichier de configuration d'au moins un objet materiel et/ou logiciel comprenant 
des parametres, ledit fichier de configuration etant ecrit en utiiisant un 
metalangage de description dont le format est independant du materiel et/ou 
logiciel a configurer, ce fichier de configuration incluant tout ou partie des 
parametres dudit objet et se reposant sur un fichier de description definissant 
des contraintes a respecter sur sa structure et sa syntaxe lors de son ecriture, 
caracterise en ce qu'il consiste. avant I'ecriture du fichier de configuration. 

- a etendre le fichier de description par au moins un module comprenant 
au moins un parametre decrit dans le fichier de description. 

- et a valoriser tout ou partie des parametres de ce modele. 

2- Procede selon la revendication 1, caracterise en ce qu'il consiste. lors 
de Tecriture du fichier de configuration, a utiliser la partie, du modele 
comprenant les parametres valorises comme facteur commun, et en ce que 
Tecriture du fichier de configuration se limite a la valorisation des parametres 
ne comportant pas de valeur. 

3- Procede selon la revendication 1 ou 2, caracterise en ce qu'il 
20 consiste, lors de la creation du modele, a regrouper les objets se reposant sur 

le meme fichier de description et ensuite a identifier les parametres dont la 
valeur est identique entre tous ces objets. et en ce qu'il consiste a valoriser ces 
parametres pour constituer un facteur commun dans ce modele. 

4- Procede selon Tune des revendications 1 a 3. caracterise en ce qu'il 
25 consiste. lors de I'ecriture du fichier de configuration, si au moins deux objets 

se reposent sur le meme modele, a utiliser le facteur commun et a valoriser 
uniquement le restant des parametres de ce modele autant de fois qu'il y a 
d'objets se reposant sur ce modele d'element. 




5- Procede selon I'une des revendications 1 a 4, caracterise en ce que 
le langage est extensilple at en ce qu'il consiste a donner un nom pour identifier 
le modeie dans le fichier de description, et en ce qu'il consiste a inclure dans le 
modele une reference du fichier de description, cette reference definissant les 
contraintes a respecter sur la structure et la syntaxe de ce modele. 

6- Procede selon I'une des revendications 1 a 5, caracterise en ce que 
le langage est extensible et en ce qu'il consiste a introduire dans un modele 
deux mots cles DEFINIR et DEFINI indiquant qu'un parametre est ^ definir 
(DEFINIR) ou est defini (DEFINI) dans ce modele. 

7- Procede selon I'une des revendications 1 a 6, caracterise en ce que 
le langage est le langage XML, et en ce qu'il consiste k prendre comme 
parametre un element et/ou un attribut d'un objet. 

8- Procede selon la revendication 7, caracterise en ce qu'il consiste a 
etendre le fichier de description par au moins un modele d'element comprenant 
au moins un parametre (element et/ou attribut) decrit dans le fichier de 
description, et a valoriser tout ou partie des param§tres de ce modele 

9- Procede selon la revendication 7 ou 8, caracterise en ce qu'il 
consiste a donner un nom pour identifier le modele d'element dans le fichier de 
description, et en ce qu'il consiste a inclure dans le modele une reference a un 
element du fichier de description, cette reference definissant les contraintes a 
respecter sur la structure et la syntaxe de ce modele. 

10- Procede selon I'une des revendication 7 a 9, caracterise en ce qu'il 
consiste a inclure dans un modele d'element au moins un modele d'element. 

11- Procede selon I'une des revendications 7 a 10, caracterise en ce 
qu'il consiste, sur requete d'une application utilisant le fichier de configuration, 
a transmettre le facteur commun et les blocs resultant de la valorisation des 
elements indefinis. 

12- Fichier de configuration d'au moins un objet materiel et/ou logiciel 
comprenant des parametres. ledit fichier de configuration etant ecrit en utilisant 
un metalangage de description dont le format est independant du materiel et/ou 
logiciel a configurer, ce fichier de configuration incluant tout ou partie des 



parametres dudit objet et se reposant sur un fichier de description definissant 
des contraintes a respecter sur sa structure et sa syntaxe lors de son ecriture, 
caracterise en ce que le fichier de description est etendu, et en ce que 
['extension comprend au moins un modele tei que defini dans Tune des 
revendications 1 a 1 1 . 
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REVENDICATIONS 

1- Precede de creation, dans un systeme informatique. d'au moins un 
fichier de configuration d'au moins un objet materiel et/ou logiciel comprenant 
des parametres. ledit fichier de configuration etant stocke dans une m6moire 
de stockage d'information et etant ecrit en utilisant un metalangage de 
description dont le format est independant du materiel et/ou logiciel a 
configurer, ce fichier de configuration incluant tout ou partie des param6tres 
dudit objet et se reposant sur un fichier de description definissant des 
contraintes a respecter sur sa structure et sa syntaxe lors de son 6criture, 
caracteris6 en ce qu'il consiste. avant Tecriture du fichier de configuration. 

- a etendre le fichier de description par au moins un module corpprenant 
au moins un parametre decrit dans le fichier de description, 

- et a valoriser tout ou partie des parametres de ce module. 

2- Precede selon la revendication 1 , caracterise en ce qu'il consiste, lors 
de Tecriture du fichier de configuration, a utiliser la partie du modele 
comprenant les parametres valorises comme facteur commun, et en ce que 
Tecriture du fichier de configuration se limite a la valorisation des parametres ne 
comportant pas de valeur. 

3- Precede selon la revendication 1 ou 2, caracterise en ce qu'il 
consiste. lors de la creation du modele, a regrouper les objets se reposant sur 
le meme fichier de description et ensuite a identifier les parametres dont la 
valeur est identique entre tous ces objets. et en ce qu'il consiste a valoriser ces 
parametres pour constituer un facteur commun dans ce modele. 

4- Proced6 selon I'une des revendications 1 a 3, caract6ris6 en ce qu'il 
consiste. lors de I'ecriture du fichier de configuration, si au moins deux objets 
se reposent sur le meme module, a utiliser le facteur commun et a valoriser 
uniquement le restant des parametres de ce modele autant de fois qu'il y a 
d'objets se reposant sur ce modele d'element. 




5- Precede selon Tune des revendications 1 a 4. caract6ris6 en ce que 
le langage est extensible et en ce qu'il consiste d donner un nom pour identifier 
le modele dans le fichier de description, et en ce qu'il consiste ^ inclure dans le 
module une reference du fichier de description, cette reference d6finissant les 

5 contraintes a respecter sur la structure et la syntaxe de ce module, 

6- Proc6de selon Tune des revendications 1 a 5, caract6ris6 en ce que 
le langage est extensible et en ce qu'il consiste a introduire dans un module 
deux mots cl6s DEFINIR et DEFINI indiquant qu'un parametre est ^ definir 
(DEFINIR) ou est d6fini (DEFINI) dans ce modele. 

10 7- Proc§d6 selon Tune des revendications 1^6, caract6ris6 en ce que 

le langage est le langage XML. et en ce qu'il consiste d prendre comme 
paramfetre un el6ment et/ou un attribut d'un objet. 

8- Proc6de selon la revendication 7, caract6ris6 en ce qu'il consiste d 
6tendre le fichier de description par au moins un modele d'§I6ment comprenant 

15 au moins un parametre (6l6ment et/ou attribut) d6crit dans le fichier de 
description, et ^ valoriser tout ou partie des paramdtres de ce modele 

9- Proc6d6 selon la revendication 7 ou 8, caract6ris6 en ce qu'il consiste 
a donner un nom pour identifier le module d'element dans le fichier de 
description, et en ce qu'il consiste d inclure dans le modele une reference a un 

20 Element du fichier de description, cette reference d6finissant les contraintes d 
respecter sur la structure et la syntaxe de ce module, 

10- Proced6 selon Tune des revendication 7 a 9, caracterise en ce qu'il 
consiste a inclure dans un module d'6l6ment au moins un modele d'6l6ment. 

11- Proc6de selon Tune des revendications 7 ^ 10. caracteris6 en ce 
25 qu'il consiste. sur requete d'une application utilisant le fichier de configuration, 

S transmettre le facteur commun et les blocs resultant de la valorisation des 
§l6ments indSfinis. 
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